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1.  Introduction 


In  1987,  the  ISI  parallel  and  distributed  computing  research  group  implemented  a  proto¬ 
type  sequential,  discrete-event  simulator  of  SDI  architectures.  An  important  design  goal 
of  this  prototype  simulation  system  software  development  effort  was  to  achieve  a  clean 
separation  between  the  candidate  being  modeled  and  the  “outside  world”  —  that  is,  be¬ 
tween  the  simulated  defense  architecture  and  the  simulated  characteristics  and  effects  of 
the  physical  environment  and  the  threat.  Additionally,  our  simulator  design  was  intended 
to  incorporate  an  abstract  yet  executable  representation  of  the  battle  management  system 
of  the  candidate  architecture  being  modeled.  These  two  central  design  goals  followed 
directly  from  our  perception  that  SDIO  needs  a  simulation  system  that  (a)  is  independent 
of  any  particular  candidate  architecture  (i.e.,  it  is  capable  of  simulating  many  different 
candidates  under  the  same  set  of  assumptions  about  environment  and  threat)  and  (b) 
includes  a  nontrivial  representation  of  the  computation  and  decision-making  performed 
by  the  battle  management  system  before  and  during  an  attack.  A  discussion  of  our  design 
approach  to  the  simulation  software  and  a  detailed  description  of  the  resulting  system  are 
provided  in  [2]. 

It  is  implicit  in  these  assumptions  about  the  requirements  of  the  simulation  system  that  we 
expect  the  simulator  to  be  used  by  many  different  people  and  for  simulating  many  differ¬ 
ent  candidate  architectures.  With  these  future  simulator  users  in  mind,  we  have  devel¬ 
oped  a  prototype  interactive  user  interface.  The  purpose  of  this  document  is  to  report  on 
the  results  of  this  prototype  development,  as  well  as  to  serve  as  a  rudimentary  manual  for 
simulator  users.  Section  2  provides  a  general  description  of  the  user  interface  and  its 
software  components,  Section  3  walks  the  reader  through  a  example  interactive  session  in 
which  a  user  sets  up  and  runs  a  simulation,  and  Section  4  contains  our  suggestions  of 
future  improvements  to  the  user  interface  software. 

2.  Overview  of  the  User  Interface 

We  used  the  same  development  philosophy  in  imi  "enting  the  prototype  user  interface 
that  we  used  when  implementing  the  simulator  itse!"  *.eep  the  design  as  simple  as  possi¬ 
ble  without  avoiding  any  difficult  design  issues.  Our  assumption  throughout  this  project 
has  been  that  we  were  not  developing  a  fully  functional,  fully  debugged,  complete  soft¬ 
ware  product,  but  instead  were  constructing  a  design  framework  in  such  a  way  that  the 
difficult,  fundamental  design  problems  were  addressed,  but  the  details  of  a  full,  “produc¬ 
tized”  implementation  could  be  added  later  without  additional  fundamental  design  prob¬ 
lems  being  encountered.  Thus,  our  user  interface  is  simple  and  primitive. 

The  user  interface  software  consists  of  several  components:  the  high-level  BMA  language 
translator,  an  interactive  session  manager,  an  output  filtering  mechanism,  a  database  for 
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storage  and  retrieval  of  simulation  output,  and  a  facility  for  graphic  display  of  simulation 
results  (see  Fig.  1).  The  database  system  and  graphics  package  are  described  in  [2],  and 
are  therefore  not  discussed  here. 

2.1  High-level  BMA  Language  Translator 

“BMA”  is  an  abbreviation  of  “battle  manager  abstraction.”  This  is  our  term  for  the  high- 
level  but  executable  programs  that  model  the  computations  of  the  defense  architecture's 
battle  management/C3  system.  A  BMA  can  be  specified  by  the  user  for  any  platform  or 
set  of  platforms  in  the  defense  architecture  being  simulated.  A  companion  report  [3] 
provides  a  detailed  description  of  “kmac,”  the  high-level  language  we  developed  for 
specifying  a  BMA.  The  translator  for  this  language  converts  a  high-level  BMA  specifica¬ 
tion  to  C++  code,  which  must  then  be  compiled  and  linked  with  the  main  body  of  the 
simulator.  The  session  manager  simplifies  this  process  by  automatically  invoking  the 
translator  and  recompiling  the  simulator  when  necessary. 

2.2  Session  Manager 

The  session  manager  is  a  menu-driven,  interactive  interface  to  the  simulator.  It  is  imple¬ 
mented  in  C++  and  runs  on  a  VAX  8650  under  4.3  BSD  UNIX.  Its  design  attempts  to 
meet  the  following  criteria:  (1)  the  user  should  be  able  to  easily  specify  new  simulation 
parameters,  including  new  candidate  defense  system  architectures  and  threat  scenarios; 
and  (2)  the  user  should  not  be  required  to  be  familiar  with  the  internal  workings  of  the 
simulator. 

To  allow  new  simulation  parameters  to  be  easily  defined,  menus  are  provided  that  prompt 
the  user  to  select  or  specify  the  following: 

1.  the  platforms  and  configuration  of  the  defense  architecture,  including  the 
platform  types,  the  platform  capabilities,  and  the  platform  deployment 
sequence. 

2.  the  high-level  language  representations  of  the  BMAs. 

3.  the  nature,  magnitude  and  timing  of  the  threat. 

4.  the  textual  or  graphic  output  desired  from  the  simulation  run. 

5.  miscellaneous  parameters,  such  as  the  starting  seed  for  the  random  num¬ 
ber  generator,  and  the  screen  update  rate. 

The  session  manager  also  maintains  a  database  of  the  current  definitions  of  the  simula¬ 
tion  parameters  for  each  user.  This  database  is  consulted  on  each  invocation  of  the  pro¬ 
gram  and  is  updated  on  exit.  Thus,  a  session  can  be  interrupted  and  easily  restarted. 
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In  order  to  mask  the  internal  structure  of  the  simulator  from  the  user,  the  session  man¬ 
ager  transparently  coordinates  the  interaction  between  the  user  and  the  other  components 
of  the  simulation  system  (see  Figure  2).  It  automates  the  process  of  translating  the  high- 
level  BMA  specifications  and  incorporating  the  resulting  code  into  the  simulator;  any 
necessary  auxiliary  files  needed  by  the  simulator  are  also  automatically  generated  from 
user  input. 

The  structure  of  the  session  manager  is  very  simple:  it  consists  of  a  set  of  C++  functions 
that  manage  the  menus  and  process  user  requests,  passing  control  to  the  other  units  in  the 
user  interface  when  necessary.  For  instance,  when  given  a  new  BMA  specification,  the 
program  automatically  invokes  the  translator,  generates  several  BMA-specific  simulation 
system  files,  and  invokes  a  shell  script  that  recompiles  the  simulator,  producing  a  new 
executable  module.  When  the  object  file  is  executed,  control  is  passed  to  the  simulator, 
which  causes  some  output  files  to  be  generated  by  the  output  filter  mechanism.  When  the 
simulation  terminates,  control  is  returned  to  the  session  manager.  Data  is  passed  between 
the  units  primarily  in  the  form  of  arguments  specifying  the  names  of  input  files  that  are 
created  by  the  session  manager  and  contain  the  information  specified  by  the  user. 

During  implementation  of  the  session  manager,  we  found  that  one  additional  feature  was 
needed:  a  locking  mechanism  that  restricts  the  concurrent  use  of  the  front-end  to  a  single 
user.  This  is  to  prevent  multiple  users  from  simultaneously  overwriting  the  system  files 
created  by  the  program  when  new  platform  types  are  defined.  The  implementation  is 
based  on  the  use  of  a  file  as  a  semaphore.  When  the  program  is  invoked,  it  attempts  to 
create  a  file  in  a  predesignated  directory.  If  the  file  already  exists,  the  creation  attempt 
will  fail  and  the  program  will  exit;  otherwise  execution  will  proceed  normally  and  the  file 
will  be  removed  upon  exit,  allowing  the  next  user  to  access  the  program. 

Section  2  provides  a  detailed  description  of  a  sample  session  illustrating  the  specification 
of  both  a  defense  system  architecture  and  a  threat  configuration. 

2.3  Output  Filtering  Mechanism 

In  order  to  obtain  meaningful  results  from  a  simulation  run,  there  must  be  some  means  of 
filtering  the  voluminous  output  from  the  simulator.  One  method  of  doing  this  is  to  con¬ 
ceive  of  the  simulator  output  as  a  single  stream  of  data  that  can  be  passed  through  a 
series  of  filters.  Each  filter  collects  some  pertinent  information  from  the  data  stream  and, 
possibly,  removes  some  data  from  it  before  passing  it  on  to  the  next  filter.  By  associating 
a  data  transformation  function  with  each  filter,  the  collected  data  can  be  summarized  into 
statistical  output  as  specified  by  the  user.  Implementing  the  filters  as  separate  processes 
executing  in  parallel  with  the  simulator  would  allow  the  computation  to  proceed  in  a 
pipelined  fashion,  resulting  in  greater  effective  utilization  of  computer  system  resources. 
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We  have  implemented  a  rudimentary  form  of  this  concept.  The  user  specifies  which  simu¬ 
lated  events  are  of  interest;  the  selected  events  are  collected  and  saved  in  output  files 
when  the  simulator  is  executed. 

3.  Example  User  Scenario 

The  user  interface  to  the  simulator  is  an  interactive  program  designed  to  allow  the  user  to 
(1)  specify  a  new  execution  environment  for  the  simulator;  (2)  recompile  the  simulator  if 
necessary;  and  (3)  run  the  simulator  with  the  newly  defined  parameters. 

In  the  following  example  of  an  interactive  session,  three  types  of  text  appear:  user  input, 
explanatory  text,  and  program  output.  User  input  is  printed  in  boldface  and  may  be 
accompanied  by  explanatory  text;  the  resulting  program  output  is  printed  in  type¬ 
writer  font.  The  symbol  represents  a  point  at  which  the  user  has  struck  the 
carriage  return  key. 


frontend  Start  up  the  program;  the  root  menu  will  be  displayed. 

***  OPTIONS  *** 

P  Platform  type  definition 

I  Input/output  file  definition 

M  Miscellaneous  parameters 

S  Show  the  current  bindings 

C  Compile 

E  Execute  the  simulator 

H  Help  message 

Q  Quit 


ENTER  YOUR  CHOICE:  !WP 


3.1  Current  Context  Display 

The  program  is  structured  as  a  hierarchy  of  menus;  the  user  selects  a  choice  by  entering 
the  appropriate  character.  The  current  simulation  parameters  are  stored  in  a  file  named 
“SUSER.context”  (with  the  actual  user’s  name  substituted  for  SUSER).  This  file  is  read 
upon  each  invocation  of  the  program;  it  contains  the  current  bindings  for  the  platform 
type  definitions,  the  names  of  the  simulator  input  files,  and  other  simulation  parameters. 
The  context  file  is  updated  with  the  new  bindings  upon  exit  from  the  program.  Selecting 
option  “S”  causes  the  current  context  to  be  displayed. 
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*******  PLATFORM  TYPES: 

No  platform  types  have  been  defined. 


INPUT  FILES: 

Platform  deployment: 
Threat : 

Capabilities : 

Filters : 

Output : 

BMA  header: 


UNDEFINED 

/u3/mizell/fysicium/src/frontend/ threat 
UNDEFINED 

/u3/mizel 1/fy sic ium/src/frontend/f lags 

coatney 

UNDEFINED 


*******  OTHER  PARAMETERS: 

Screen  Update  Rate:  5 

Seed:  1 


.  . . .  Type  <CR>  to  continue: 


Initially,  the  user  is  assigned  a  default  context.  Items  that  are  marked  UNDEFINED  must 
be  defined  before  the  simulator  can  be  executed.  Each  of  the  items  in  the  context  will  be 
described  more  fully  as  the  session  proceeds.  Typing  a  carriage  return  (CR)  returns  us  to 
the  root  menu,  where  we  select  option  “P”  to  define  some  platform  types. 

3.2  Platform  Type  Definition 

p+> 


**•  CURRENT  PLATFORM  TYPES  *** 

No  platform  types  have  been  defined. 
BMA  header :  UNDEFINED 

***  OPTIONS  ••* 

B  Define  a  BMA 
H  Specify  the  BMA  Header  File 
A  Abort  this  session 
Q  Quit  this  menu 

ENTER  YOUR  CHOICE: 


This  display  contains  two  sections  —  a  description  of  the  currently  defined  platform 
types,  and  a  menu  of  options.  A  platform  type  is  characterized  by  its  name,  which  is 
chosen  by  the  user  and  must  be  unique,  and  the  name  of  its  BMA.  Selecting  option  “B” 
allows  the  user  to  define  a  new  platform  type.  The  user  is  then  asked  to  enter  the  name  of 
the  platform  type  and  the  name  of  the  file  containing  the  high-level  source  code  for  the 
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After  defining  platform  type  dummy2  (not  shown),  we  select  option  “H”  to  define  the 
name  of  the  BMA  header  file.  This  header  file  should  contain  all  definitions  of  user-de¬ 
fined  types  that  appear  in  the  definition  of  BMA  persistent  variables.  If  no  header  file  is 
needed  (i.e.,  only  base  types  or  simulator  system  defined  types  are  used  for  persistent 
variable  definitions)  this  parameter  should  be  set  to  UNDEFINED. 


Set  the  i no " ade  file  to  UNDEFINED?  (Y/N) 

Name  of  the  include  file:  dummybma.h«> 

. . . .  Type  <CR>  to  continue :■+> 


3.3  Input/Output  File  Definition 

We  now  return  to  the  root  menu  by  quitting  the  current  menu,  and  select  the  input/output 
file  definition  menu.  Information  is  passed  between  the  session  manager  and  the  simula¬ 
tor  in  the  form  of  arguments  that  specify  the  names  of  input  files  created  by  the  session 
manager  and  that  contain  the  information  supplied  by  the  user.  This  menu  allows  the  user 
to  define  the  contents  of  those  files,  which  include  descriptions  of  the  platform  deploy¬ 
ment,  the  platform  capabilities,  the  threat  scenario,  the  output  filters,  the  basename  for 
the  output  files  created  by  the  simulator,  and  the  BMA  header  file.  The  current  input  file 
names  are  shown  in  the  upper  portion  of  the  display. 
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I 


Q^> 

I+> 


***  CURRENT  INPUT/OUTPUT  FILES  «** 


Platform  Deployment: 
Threat : 

Capabilities : 

Filters : 

Output : 

BMA  Header : 


UNDEFINED 

/u3/mizell/fysicium/src/frontend/threat 

UNDEFINED 

/u3/mizell/fysicium/src/frontend/f lags 
coatney 

/u3/mizel 1/fysicium/src/frontend/dummybma . h 


***  OPTIONS  *** 

D  Platform  Deployment 

C  Platform  Capabilities 

T  Threat  Scenario 

F  Output  Filters 

0  Output  file  basename 

A  Abort  this  session 

Q  Quit  this  menu 


ENTER  YOUR  CHOICE:  D^P 


3.3.1  Platform  Deployment 

We  will  first  define  the  platform  deployment.  The  user  can  either  specify  the  name  of  an 
existing  file  (previously  defined  using  this  program)  or  define  a  new  one.  For  each  plat¬ 
form  type,  the  user  must  designate  the  number  of  platforms  of  that  type  and  the  trajecto¬ 
ries  of  those  platforms.  Currently,  two  types  of  trajectories  have  been  implemented  — 
geostationary  and  walker  (see  [2]  for  details  on  trajectories). 


Use  an  existing  deployment  file?  (Y/N) 

Enter  the  name  of  the  deployment  file:  mydeploy^P 

*•*  How  many  platforms  of  type  dummyl? 

Trajectory  type:  <G>  geostationary,  <W>  Walker  orbits: 

Longitude  of  dummyl  platform  0:  90-55 

***  How  many  platforms  of  type  dummy2?  3-S3 

Trajectory  type:  <G>  geostationary,  <W>  Walker  orbits: 

Number  of  rings  in  Walker  orbits:  l-*3 
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Latitude  of  the  maximum  coverage  point: 
Longitude  of  the  maximum  coverage  point: 


45-i3 


90S> 


....  Type  <CR>  to  continue: 

3.3.2  Platform  Capabilities 

We  return  to  the  input/output  file  menu,  and  select  “C”  to  define  the  platform  capabili¬ 
ties.  Note  that  the  user  must  know  what  capabilities  to  assign  to  each  platform  type.  If  the 
capabilities  are  not  correctly  assigned,  the  simulation  may  not  execute  successfully  (see 
the  suggestions  for  future  improvements  of  the  simulation  system  in  Section  5). 

The  program  maintains  an  internal  listing  of  the  currently  implemented  technology  mod¬ 
ules  (see  [1,  2]).  For  each  such  module,  the  user  is  asked  to  specify  how  many  devices  of 
that  type  to  assign  to  the  capabilities  list  of  each  currently  defined  platform  type. 


Use  an  existing  capabilities  file?  (Y/N)  n-5> 

Enter  the  capabilities  filename:  mycap5> 

***•  Defining  capabilities  for  platform  type  [dummyl] : 

How  many  sensors  of  type  STARING_SENSOR?  l-5> 

How  many  channels  of  type  CHANNELO?  15P 

How  many  weapons  of  type  LASER?  (UP 

*•**  Defining  capabilities  for  platform  type  [dummy2] : 

How  many  sensors  of  type  STARING_SENSOR?  &5> 

How  many  channels  of  type  CHANNELO?  UP 

How  many  weapons  of  type  LASER?  dip 


.  . . .  Type  <CR>  to  continue: 


3.3.3  Threat  Scenario 

Next  we  select  option  “T”  to  define  the  threat  scenario.  The  current  version  of  the  user 
interface  allows  only  a  very  limited  specification  of  the  threat  scenario.  The  deployment 
sequence  of  the  missiles  consists  of  the  number  of  missiles  to  launch,  the  launch  time  of 


the  first  missile,  and  the  interval  between  launches.  The  program  arbitrarily  assigns 
values  for  the  initial  position  of  the  missiles  and  their  targets. 


Use  an  existing  threat  file?  (Y/N) 

Enter  the  threat  filename:  mythreat4p 

Number  of  missiles: 

Time  to  begin  launching  missiles  (seconds) :  5-S3 

Interval  between  launches  (seconds):  10-i5 


Type  <CR>  to  continue:  ■+> 


3.3.4  Output  Filters 

In  order  to  obtain  meaningful  results  from  a  simulation  run,  there  must  be  some  means  of 
filtering  the  voluminous  output  from  the  simulator.  One  method  of  doing  this  is  to  con¬ 
ceive  of  the  simulator  output  as  a  single  stream  of  data  that  can  be  passed  through  a 
series  of  sieves.  Each  sieve  collects  some  pertinent  information  and,  possibly,  removes 
some  data  from  the  stream  before  passing  the  stream  on  to  the  next  sieve.  The  sieves 
could  be  implemented  as  separate  processes  executing  in  parallel  with  the  simulator. 

We  have  implemented  a  simple  version  of  this  concept.  The  user  specifies  which  events 
are  of  interest;  the  specified  events  will  be  collected  and  saved  in  output  files  when  the 
simulator  is  executed. 


F*P 


Use  an  existing 

filters  file7 

(Y/N) 

Enter 

the 

filters  file  name: 

myfilters^ 

Print 

out 

event 

type 

SHOOT? 

(Y/N) 

Print 

out 

event 

type 

DESTROY? 

(Y/N) 

Print 

out 

event 

type 

BMA  SENSE? 

(Y/N) 

Il4p 

Print 

out 

event 

type 

SAMPLE? 

(Y/N) 
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Print 

out 

event 

type 

SENSE  APPEAR? 

(Y/N) 

y*> 

Print 

out  relevant  data  ? 

(Y/N) 

y*> 

Print 

out 

event 

type 

SENSE  DISAPPEAR? 

(Y/N) 

Print 

out  relevant  data  ? 

(Y/N) 

n-i5 

Print 

out 

event 

type 

SENSE  BLOWNUP? 

(Y/N) 

n+> 

Print 

out 

event 

type 

LAUNCH? 

(Y/N) 

y^ 

Print 

out 

event 

type 

NUKE? 

(Y/N) 

y^ 

Print 

out 

event 

type 

BMA  DELAY? 

(Y/N) 

y^ 

Print 

out 

event 

type 

BMA  COMM? 

(Y/N) 

y-s* 

Print 

out 

event 

type 

BMA  INIT? 

(Y/N) 

y*> 

Print 

out 

event 

type 

PRINT  POSITION? 

(Y/N) 

y*> 

start 

time 

=  OS5 

end  time 

=  30-S> 

delta 

time 

= 

.  .  .  .  Type  <CR>  to  continue:  -*P 


The  filtered  output  is  written  to  files  created  by  the  simulator.  The  names  of  the  files  are 
created  by  concatenating  a  base  name  (by  default  the  name  of  the  current  user)  with  the 
following  set  of  strings: 

.err  (error  file) 

.evnt  (filtered  events) 

.in  (input  parameters  and  file  names) 

.msgs  (inter-platform  messages) 

.pos  (platform  and  missile  positions) 

.trg  (trajec  ,ry  data) 

.db.evnt  ■  its  in  database  format) 

.db.pos  (pic-  o.m  and  missile  positions  in  database  format). 

The  basename  of  the  files  can  be  changed  by  selecting  option  “O”. 
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Enter  the  base  name  for  the  simulator  output  files:  siml 
. . . .  Type  <CR>  to  continue: 


3.4  Miscellaneous  Parameters 

Since  all  the  input/output  parameters  have  now  been  set,  we  return  to  the  root  menu  and 
select  option  “M”  to  inspect  the  remaining  miscellaneous  simulation  parameters  —  the 
random  number  generator  seed  and  the  screen  update  rate. 

The  seed  is  passed  to  the  simulator  to  serve  as  the  seed  for  a  random  number  stream.  The 
default  value  of  “1”  should  be  changed  by  either  directly  specifying  a  new  value  for  the 
seed  or  by  requesting  that  the  program  assign  a  random  value  (at  present,  the  value  of  the 
current  time  as  returned  by  the  UNIX  system  call  gettimeofday  is  used  as  the  random 
value). 

The  screen  update  rate  is  the  rate  (real  time)  at  which  the  current  simulation  time  is 
reported  to  the  user  while  the  simulation  is  proceeding;  this  is  useful  only  for  very  long 
simulation  runs,  and  is  specified  in  units  of  seconds. 

Q-S* 

***  CURRENT  SIMULATION  PARAMETER  VALUES  *** 

Screen  Update  Rate:  5 

Seed :  1. 

«**  OPTIONS  *** 

R  Random  number  generator  seed 

S  Screen  update  rate 

A  Abort  this  session 
Q  Quit  this  menu 

ENTER  YOUR  CHOICE: 


Setting  the  miscellaneous  parameters  is  straightforward,  and  therefore  will  not  be  demon¬ 
strated. 
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3.5  Compiling  the  Simulator 

We  are  ready  to  return  to  the  root  menu  and  compile  the  simulator.  The  program  creates 
several  system  files,  then  attempts  to  compile  and  link  the  simulator  by  invoking  the 
UNIX  utility  make.  Diagnostic  messages  are  printed. 


IS  A  FULL  COMPILATION  NEEDED?  (if  you  don't  know,  type  y) :  (Y/N)  y-S> 

Creating  file  [/u3/mizell/fysiciura/include/init_plats . h] 

Creating  file  [/u3/mizell/fysicium/src/objects/init_plats . c] 

Creating  file  [/u3/mizell/fysiciuni/src/misc/bma . c) 

Creating  file  t/u3/mizell/fysicium/include/bma_pvars.h] 
set  umask  000 

cd  /u3/raizell,/fysicium/src 
*****  BEGIN  COMPILING  ***** 

make  -s  NEWBMAH=/u3/mizell/fysicium/ src/f rontend/dummybma . h 
CC  objects. c: 

CC  init_plats . c : 

CC  bma . c : 

cc  -p  simulator. o  ../.. /lib/libS. a  . . / . . /lib/libS2 . a  -lm  -o 
newsim  -1C 

***  FINISHED  COMPILING  *** 


.  .  . .  Type  <CR>  to  continue: 


Usually  a  full  compilation  is  necessary.  In  that  case,  the  system  generates  four  C++  source 
files  that  contain  (1)  declarations  of  BMA-related  global  variables;  (2)  definitions  of  func¬ 
tions  used  for  initializing  platform  capabilities;  (3)  the  translated  BMA  code;  and  (4)  the 
declarations  of  BMA  persistent  variables.  A  full  compilation  does  not  imply  that  all  of  the 
simulator  system  code  must  be  recompiled.  On  the  contrary,  only  three  source  files 
require  compilation.  The  resulting  object  code  is  then  linked  with  the  remaining  system 
code  to  produce  a  new  executable  image.  A  partial  compilation  causes  only  the  translated 
BMA  code  to  be  compiled. 

There  are  several  possible  reasons  for  the  compilation  phase  to  fail.  The  BMA  code  may 
be  incorrect,  in  which  case  the  user  should  follow  these  steps: 

1.  edit  the  offending  BMA  source  code 

2.  redefine  the  platform  type  (this  will  cause  the  source  code 
to  be  translated  into  C++  code) 

3.  compile  the  simulator  (partial  compilation  is  sufficient). 
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If  the  source  code  is  correct,  the  user  should  verify  that  all  user-defined  types  used  in  the 
definition  of  persistent  variables  appear  in  the  BMA  header  file,  and  make  sure  that  the 
appropriate  header  file  was  specified.  If  any  changes  were  necessary,  recompile  the  simu¬ 
lator  (full  compilation). 

3.6  Executing  the  Simulator 

From  the  root  menu,  we  select  option  “E”  to  execute  the  simulator.  First  the  input  pa¬ 
rameters  are  printed,  then  any  output  from  the  BMAs.  The  references  to  New  Zealand  are 
a  side  effect  of  the  enemy  missiles  successfully  destroying  their  targets. 

E^> 


USER  =  coatney 

DATE  =  Mon  May  9  17:32:19  1988 
PLATFORM  FILE  =  mydeploy 
THREAT  FILE  *  mythreat 
CAPABILITY  FILE  «  mycap 

***  BEGIN  SIMULATION 

platform  [0]  entered  BMASENSE  at  time  [8.000000] 
platform  [0]  entered  BMA_SENSE  at  time  [18.000000] 
platform  [0]  entered  BMA_SENSE  at  time  [28.000000] 

...  verbose  output  deleted  ... 

WE  SHOULD  HAVE  GONE  TO  NEW  ZEALAND 
WE  SHOULD  HAVE  GONE  TO  NEW  ZEALAND 
WE  SHOULD  HAVE  GONE  TO  NEW  ZEALAND 
***  END  SIMULATION 

....  Type  <CR>  to  continue: 


We  are  now  back  at  the  root  menu.  Any  or  all  of  the  input/output  files  and  miscellaneous 
parameters  can  be  changed  and  a  new  simulation  run  can  be  made  without  requiring 
recompilation.  However,  if  a  new  BMA  or  platform  type  is  added,  the  simulator  must  be 
recompiled  before  execution.  This  concludes  the  demonstration  of  the  interactive  user 
interface. 

4.  Suggested  Improvements 

We  offer  the  following  suggestions  to  future  maintainers  of  this  system: 

1.  Currently,  the  capabilities  must  be  separately  defined  through  the  session  manager, 
thus  the  user  of  the  program  must  know  what  capabilities  to  assign  to  each  platform  type. 
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A  better  approach  would  be  to  specify  the  platform  capabilities  as  part  of  the  high-level 
LMA  definition.  The  kmac  parser  could  then  automatically  generate  entries  for  each  plat¬ 
form  type  in  the  capabilities  file. 

2.  The  program  should  allow  more  detailed  specification  of  the  threat  scenario,  in  which 
the  user  could  specify  the  initial  position,  target,  and  launch  time  of  each  missile. 

3.  There  should  be  an  option  to  display  the  contents  of  the  current  simulator  input  files  in 
some  intelligible  format. 

4.  The  program  should  be  ported  to  Xwindows  [4],  This  would  allow  remote  execution 
and  a  more  sophisticated  user  interface. 

5.  A  facility  should  be  provided  for  removing  previously  defined  platform  types  from  the 
context.  The  only  way  to  do  this  now  is  to  manually  edit  the  context  file. 
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Figure  1.  User  interface  software  components 


The  session  manager  allows  new  simulation 
parameters  to  be  easily  and  rapidly  speci¬ 
fied  and  coordinates  user  interaction  with 
other  simulation  system  components. 


Figure  2.  Interactions  between  user  interface  components 
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